THE BELL SYSTEM TECHNICAL JOURNAL 
Vol. 62, No. 7, September 1983 
Printed in U.S.A. 



Total Network Data System: 
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The Total Network Data System (TNDS) includes a subsystem that meas- 
ures TNDS performance and assists network administrators and those re- 
sponsible for network traffic data collection in finding TNDS troubles. This 
interactive subsystem provides the telephone company managers with a ver- 
satile tool for a performance analysis of the many systems and organizations 
associated with TNDS. The troubleshooting features usually provide sufficient 
detail from which to specify corrective action. The performance information 
can be aggregated across all organizational levels from the single traffic unit 
to the entire Bell System. 

I. INTRODUCTION AND SUMMARY 

Good service to the customer has always been a hallmark of the Bell 
System. This service is ensured by a number of measurement plans 
used by Bell System managers to monitor the quality of service to the 
customer. Operations such as those associated with the Total Network 
Data System (TNDS) do not all have an immediate effect on the 
customer, but if neglected for a long period of time, could result in 
costly engineering mistakes. Thus, a TNDS performance measurment 
plan is needed so that the efficiency and integrity of TNDS operations 
are maintained at a level sufficient to support continued good service 
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to the customer at reasonable cost. A TNDS Performance Measure- 
ment Plan (TPMP) was introduced in 1980. This measurement plan 
is highly automated, using a computerized support system called the 
Centralized System for Analysis and Reporting (CSAR). 

In addition to highlighting performance, measurement plans often 
provide supplementary data useful to those responsible for assuring 
good performance. This function is especially important in TNDS 
operations because of the wide diversity in systems, organizations, 
geography, and timing associated with TNDS. Thus, assisting trou- 
bleshooting is an important feature of CSAR. It often allows the 
analyzer to identify the specific source of a data problem while still at 
the terminal. 

II. TNDS PERFORMANCE MEASUREMENT PLAN (TPMP) 
2.1 Need and objectives 

In 1976, as the TNDS systems were being widely deployed in the 
Operating Telephone Companies (OTCs), TNDS project managers at 
AT&T and systems engineers at Bell Labs undertook a field study of 
TNDS Operations in South Central Bell. This company offered an 
ideal environment for observing TNDS operations. Its applications 
included rural areas and large metropolitan areas across five states. 

With the help of South Central employees, personnel at Bell Labo- 
ratories and AT&T were able to obtain valuable insight into TNDS 
performance and typical operations. Over several months the AT&T/ 
Bell Labs team observed just how TNDS traffic data reports were 
obtained, and how accompanying TNDS administrative information 
was analyzed and used in a variety of operating company offices. It 
was observed that managers often had difficulty obtaining an overview 
of performance from the administrative reports generated by the 
various systems of the TNDS. Also, the geographical diversity of these 
systems, the time interval over which traffic data progress through 
the TNDS, and the volume of the reports from the systems all made 
it difficult and time-consuming to detect and pinpoint data problems. 
These difficulties were the result of the increasing size and complexity 
of TNDS and its wide deployment. 

This study clearly pointed out a need for a comprehensive, auto- 
mated performance measurement plan that could help to localize 
traffic data problems. The reports associated with the measurement 
plan should provide a concise management overview with enough 
detail about the type and location of problems to allow managers to 
apply resources to bring about solutions. The system generating the 
measurements should also make available to the TNDS administrators 
selected, detailed information about data as the data pass through the 
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various systems in the TNDS. The measurement system should allow 
enough investigation, in increasing detail, to identify the location and 
time of problems. Such investigation should also identify enough about 
their cause to determine either the corrective measures or the testing 
and analysis that is required. The traffic data problems should be 
identified as quickly as possible so that critical traffic data studies are 
not jeopardized. 

All of these requirements are best met by a system that obtains 
performance data directly from the other TNDS systems and provides 
a variety of reports on an on-line, interactive basis. 

In considering measurement plans for TNDS, we noted a significant 
trend in other Bell System measurement plans. A measurement task 
force has recommended that measurement plans should avoid aver- 
aging results since they are aggregated together for several measured 
entities. This is important so that poor performance in one or two 
entities is not masked by good performance in a number of other 
entities. This principle is extremely valid in TNDS operations mea- 
surements where consistently poor performance in obtaining traffic 
data for an office could deny engineers the data needed to plan for its 
growth. 

The method being adopted in Bell System measurement plans to 
preserve isolated indications of poor performance is to associate the 
results obtained for each measured entity into one of four bands: H, 
O, L, or U. The bands are designated as Higher than objective, 
Objective, Lower than objective, and Unsatisfactory. Then, aggregated 
results give the number of entity measurements in each of the bands. 
Thus, a poor performer is never lost in the crowd. In TPMP, there is 
usually no extra expenditure for flawless performance so there is no 
need for the Higher than objective category. Thus, TPMP only in- 
cludes bands 0, L, and U. 

The measures important in monitoring TNDS performance are 
related to data completeness, data validity, and the accuracy of the 
record bases that associate the data with the telecommunications 
equipment. The TNDS Central Office Equipment Reports (COER) 
systems, 1,2 Trunk Servicing System (TSS), 3 and Load Balance System 
(LBS) 1 all present traffic data to end users (engineers or administra- 
tors) and, thus, can supply comprehensive information about TNDS 
performance. They all provide performance data to CSAR. The Trunk 
Forecasting System (TFS), 3 also an end-user system, does not provide 
data to CSAR at this time, but its inputs are directly dependent on 
the (CSAR-measured) TSS. The Traffic Data Administration System 
(TDAS), 1 which is an intermediate system in TNDS data flow, also 
makes available performance data to CSAR. This is done because 
TDAS is the final TNDS system for certain special study information 
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and equipment types, and because analysis of TDAS results can allow 
early detection and isolation of data-gathering problems. 

The above systems generate performance data pertinent to data 
completeness, data validity, and record base accuracy. In addition, the 
Individual Circuit Analysis System (ICAN) 1 was designed primarily 
to help administer the record base for usage data acquired on individual 
circuits through the Individual Circuit Usage Recording (ICUR) ver- 
sion of the Engineering and Administrative Data Acquisition System 
(EADAS). 4 As such, ICAN is an important source of CSAR record 
base performance data for those switching systems served by EADAS/ 
ICUR. 

2.2 Performance measures 

Each system that furnishes CSAR with performance data has its 
own validity checks, record bases, and schedules. Each has its own 
way of measuring data completeness, data accuracy, and record base 
accuracy. Hence, the first level of the hierarchy for CSAR reporting 
is by the TNDS. Table I shows the TNDS performance measures 
generated by CSAR and gives a brief explanation for each. The results 
are reported as "problems," i.e., as percentage of missing data, validity 
failures, or record base errors. Two thresholds are assigned to each 
measure to distinguish between the three bands, 0, L, and U. The 
threshold settings are determined differently for each measure because 
each is associated with a different part of the TNDS process, different 
operations, or different equipment. There is a guiding rationale, how- 
ever, applied to all. The Objective band starts at zero and includes 
performance levels where minor flaws occur but are being attended to. 
The first threshold marks the transition to Band L, where the equip- 
ment errors and record base errors become significant and systematic. 
The upper threshold, which marks the beginning of band U, is set to 
indicate equipment problems that persist longer than is normally 
necessary for their remedy or to indicate the accumulation of record 
base errors. 

2.3 Reporting 

TPMP is designed to assist operating company TNDS managers at 
all organizational levels. Their access to reports is through the on- 
line, interactive computer system, CSAR. As mentioned earlier, the 
first level in the CSAR reporting hierarchy is the TNDS, from which 
CSAR has obtained the performance data. The second level is the 
organization for which the manager is responsible. For a given request, 
results from all reporting units, switching offices, trunk services, etc., 
in that organization are summarized or delineated according to the 
request. The dialogue with the computer enables the manager to get a 
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breakdown by the next lower organizational level. More will be said 
later about these reports and the manager's use of them. In addition, 
CSAR furnishes detailed information for trouble analysis. 

An overall summary of results for each TNDS operating company 
is made available to AT&T every month. The percentage of reporting- 
unit measures (see Table I) in the bands L and U are included in a 
Bell System measurement summary called "Network Results," which 
is published monthly for Bell System use. 

III. THE CENTRALIZED SYSTEM FOR ANALYSIS AND REPORTING 

CSAR is an on-line, interactive computer system that provides dial- 
up access six days a week to centralized databases holding over 250M 
bytes of information. The system combines the cost effectiveness of 
batch processing large volumes of data with the speed and convenience 
of on-line database access. CSAR can be accessed using almost any 
110-, 300-, or 1200-baud asynchronous terminal. The daily operation 
of CSAR combines the resources of OTC computer facilities in 24 
states, a Bell System data transmission network, a centralized com- 
puter system at AT&T, and the Direct Distance Dialing (DDD) 
network to support the TPMP and generate extensive information to 
assist in the operation and administration of TNDS. The reporting 
capabilities offer timely assessments of the performance of the traffic 
data collection and processing tasks, as seen by each system in the 
TNDS. Currently, eighteen OTCs use CSAR. Each TNDS installation 
within these companies becomes a remote source of TNDS perform- 
ance data analyzed by CSAR and maintained in the central databases. 
Authorized users in each of these companies have dial-up access to 
the interactive component of CSAR, allowing flexible retrieval of 
information pertinent to their own company and certain Bell System 
results. 

3. 1 System configuration 

The major component in the CSAR system configuration resides at 
the centralized computer site and receives the majority of its data from 
the distributed OTC TNDS processing sites via the Bell System 
telecommunications software system for computer-to-computer data 
exchange with OTCs (T-TRAN) data transmission network. The 
CSAR users gain access to the central computer system from existing 
remote terminals using the standard DDD telephone network. Thus, 
the system includes five major components that effectively combine 
existing Bell System facilities: 

1. Distributed OTC computer sites 

2. A T-TRAN data network 

3. A Central AT&T computer site 
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4. A DDD telephone network 

5. Existing remote terminals. 

Figure 1 shows the CSAR computer system configuration. The CSAR 
implementation utilizes and coordinates a number of different hard- 
ware and operating system environments. Brief descriptions of the 
first three system components listed above illustrate the overall CSAR 
operating environment. 

3.1.1 OTC computer facilities 

The CSAR measurement process begins at the OTC's computer 
facility when the batch TNDS subsystem modules are run. It uses the 
Standard Operating Environment of IBM 370 series mainframe or a 
compatible computer running the Multiple Virtual Storage (MVS) 
operating systems. The performance data are gathered by software 
embedded in the individual TNDS subsystem modules. Thus, the 
individual TNDS subsystems accumulate the majority of the raw data 
required for CSAR performance measurement and analysis. A stand- 
alone CSAR module executes under this environment at the remote 
computer facilities to merge the data files from the separate TNDS 
components and prepare a single standard interface for data trans- 
mission. 

3.1.2 T-TRAN data network 

Each OTC uses the T-TRAN network as a data link for the trans- 
mission of its TNDS performance data to the central computer site at 
an AT&T Corporate Computer Center in New Jersey. Weekly CSAR 
transmissions are an integral part of the TNDS operations in the 
OTCs. Backup data are retained in each company on disk or tape. 

The receipt of a transmission at the AT&T T-TRAN site (an IBM 
370 system running MVS with the time-sharing option) automatically 
invokes a CSAR program that initiates the CSAR batch processing 
sequence. This first step identifies the incoming CSAR data files and 
sends all necessary information to a second computer system that is 
the actual host for the primary CSAR batch and on-line interactive 
processes. The program under the Multiple Virtual Storage/Time- 
Sharing Option (MVS/TSO) communicates to the CSAR host ma- 
chine via a local Inter-Processor Communication (IPC) network. 

3.1.3 Central host computer 

The heart of the CSAR system also resides on one of the many 
computers that comprise the AT&T Corporate Computer Center. The 
CSAR software is developed and centrally executed on an Amdahl 470 
series mainframe running under the Virtual Machine (VM) operating 
system using the Conversational Monitor System (CMS). This VM/ 
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CMS computer facility is the home of two other TNDS centralized 
operation support systems: the Stored Program Control System Cen- 
tral Office Equipment Reports system (SPCS COER) 2 and the Small 
Office Network Data System (SONDS). 5 Performance data are sent 
directly from SPCS COER to CSAR through a VM/CMS remote 
spooling interface. 

This central host computer system offers the facilities and the 
processing capacity required by CSAR functions. The large volumes 
of data received from the 26 remote TNDS processing sites currently 
sending data to CSAR are scheduled for overnight processing using 
the VM/CMS batch facility. The analysis, correlation, and database 
loading occur during off-business hours at a reduced cost and without 
interfering with the typical interactive user. 

IV. CSAR ON-LINE FEATURES 

The primary purpose of CSAR is to provide on-line interactive 
access to central databases that contain extensive TNDS performance 
information. The on-line CSAR features can be logically grouped into 
four general categories: 

1. On-line user documentation 

2. TNDS performance reporting 

3. Database and processing controls 

4. Administrative information reporting. 

The many features work together, thereby enabling each OTC to tailor 
the database capacity and reporting strategy to its own data require- 
ments, organizational structure, and management needs. 

The following paragraphs present an overview of the CSAR features 
categorized above. The description will also highlight the on-line 
reporting techniques and selected features that distinguish CSAR as 
an innovative approach to special-purpose on-line database access and 
reporting. 

4. 1 Interactive user dialogue 

The CSAR interactive dialogue begins with the highest-level 
prompt: REQUEST =, which allows the user to select a system feature. 
The dialogue proceeds in a question and answer fashion until the user 
enters a specific request or inquiry. 

The CSAR interactive user dialogue is designed to offer a user- 
friendly interface. The dialogue design gives the inexperienced user 
specific direction and guidance when questions and problems arise. 
For the experienced user, an abbreviated dialogue sequence can be 
strung together on a single line to save typing and interaction time. 
The user dialogue allows flexible inquiry and reporting. For frequent 
requests of tailored reports, the dialogue sequence can be defined once, 
saved, and activated when the need arises. 
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4.2 On-line documentation 

A fundamental goal of CSAR is to be a totally on-line interactive 
tool that includes all necessary user documentation. Within CSAR, 
user documentation is available on-line in the form of 40 lessons that 
cover all aspects of CSAR use and administration. A particular lesson 
can be retrieved on-line at the user's terminal or printed off-line and 
mailed to specified address. This form of documentation is timely and 
easy to maintain, and eliminates the many problems associated with 
distribution lists and central reproduction. 

4.3 Performance reporting 

CSAR performance reports present data in predefined formats. 
Report content, however, is dynamically retrieved and prepared to 
satisfy specific user needs. The flexibility of the CSAR reporting 
mechanism lies in four levels of data selection available to the user. 
The first level, Report Type, identifies a particular enumeration or 
summarization of the performance data and implies an associated 
physical format. The second level, System, selects one, or possibly all, 
systems in the TNDS. The third and most versatile level of selection 
is Organization. The user can select one or more reportable entities, 
traffic units, by naming the organization to which they belong. The 
company organization structure (known as the organizational map) is 
defined to the system by the CSAR company coordinator or adminis- 
trative user as part of start-up procedures and can be dynamically 
modified whenever necessary. The CSAR map is more fully described 
later in this section. The fourth level, Time, specifies the calendar 
dates for which results are desired. The performance report request, 
and the underlying database retrieval, are defined by the composite of 
these selection criteria: Report Type, System, Organization, and Time. 
Any additional specifications are supported by a list of Options that 
are different for each report type. 

There are four general types of performance reports: 

1. Performance Indicator reports 

2. Performance Summary reports 

3. Performance Monitor reports 

4. Unsatisfactory Results Display reports. 

The following paragraphs describe the purpose and basic character- 
istics of these four report types. Specific examples of reports, their use 
by the OTC personnel, and the benefits to overall TNDS operations 
are discussed. 

4.3.1 Performance indicators 

The Performance Indicator Reports (PIRs) are intended for weekly 
troubleshooting of TNDS operational problems and data abnormali- 
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ties. Those personnel most immediately responsible for data admin- 
istration for the various TNDS systems access CSAR on a regular 
basis to detect these problems and isolate their causes. A PIR exists 
for each system in the TNDS scored under the TPMP. A PIR request 
retrieves weekly traffic unit data pertinent to one system in TNDS 
for any specified company organization. The performance measure- 
ments that appear on these weekly reports include those listed in 
Table I. The measurements typically quantify indications of missing 
data, validation failures, and record base inconsistency or errors. The 
report content is formatted as one line per traffic unit so the data for 
many traffic units can be scanned quickly. All performance measure- 
ment values that fall into the Unsatisfactory band are highlighted on 
the report. 

Options are available with the PIR that make it even more powerful 
as a troubleshooting tool. These include "history" and "exception" 
options, which can be included in the initial PIR request, and the 
"detail" option, which can be selected after the PIR has been printed 
and perused. The history option allows inclusion of up to 15 previous 
weeks of information on the PIR. The exception option causes CSAR 
to report information on only those units for which one or more of the 
week's performance measures exceed the band U threshold. The 
history and exception options may both be exercised on the same PIR 
request to highlight offices consistently performing unsatisfactorily. 

The detail option is somewhat open-ended. After the PIR is printed 
for a given week, organization, and TNDS system, the user can request 
details for any Traffic Unit (TU) in the report. After the detailed 
report for that unit is produced for the given week and TNDS system, 
the user is asked if details are desired for the same unit and week for 
another system in the TNDS. Thus, where applicable, the user can 
look upstream in the TNDS to see where problems first appeared in 
the TNDS process or downstream to see their ultimate effect. This 
may be very helpful in tracking down subtle problems. 

There are too many combinations of PIRs and options to describe 
here, but a typical example of analyzing results and problems using a 
few reports should be indicative of the assistance provided by CSAR. 
Figure 2 shows a PIR for the No. 5 Crossbar Central Office Equipment 
Reports System (5XB COER) 1 for one district. An administrator 
responsible for monitoring 5XB COER results can obtain this report 
through the dialogue shown on the top two lines of the figure. In the 
dialogue, the questions from CSAR are in the large type to the left of 
"=:" followed by the user inputs in the smaller type. No options were 
selected in this example. 

The report header identifies the report type, organization, and study 
date. As we can see in Fig. 2, this is the 5XB COER Performance 
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Fig. 2— Performance indicator report for the 5XB COER for one district. 

Indicator Report for the New Orleans District of South Central Bell 
for the traffic study week of 11/15/81. A data header (feature ® of the 
figure) identifies the performance measurement data below. Under 
TRAFFIC UNIT, feature CD, five 11 -character TU Common Language 
codes are shown. These are grouped together by the various organi- 
zations directly subordinate to the district being reported. Three sub- 
districts (NODI, NOD2 and NOD4) are shown. Thus, any performance 
pattern associated with the subordinate organizational level would be 
obvious to the district level. 

The next two columns, feature ®, pertain to the 5XB COER 
performance measure, MISSING DATA. The first of these columns 
shows the number of one-hour intervals expected for each TU by the 
5XB COER system. These expectations are a part of the 5XB COER 
record base. The next column indicates missing traffic data, both the 
expected percentage and the number of one-hour intervals. The aster- 
isk for MRCYLAINMGO indicates the percent of missing data for 
this week exceeds the band U threshold. Quick response to correct the 
deficiency will prevent it from persisting long enough to be band U 
for the official reporting period of one month. 

The next four columns, feature ®, provide supplementary informa- 
tion resulting from CSAR automatically attempting to indicate the 
source of any missing data. In this case, the five one-hour missing 
intervals for MRCYLAINMGO are accounted for in the first column 
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by a deficient Traffic Measurement Request (TMR). (TMRs are used 
to request that intervals be passed from TDAS to the downstream 
systems such as 5XB COER, if perhaps an interval was missing from 
the TMR.) The next column of this feature contains supplementary 
information indicating that there were no deficiencies in the schedul- 
ing of this data from the collection machine to TDAS. The "X" in the 
following column, Collection Machine Outage (CM OUT), indicates 
that there were disturbances in the collection phase of TNDS some- 
time during the intervals when data were gathered for 5XB COER. 
But since all data have been accounted for, these must have been 
minor. The last of these four columns indicates that no unexpected 
data (NOT EXP) was received for any TU. That is, TDAS did not 
forward to 5XB COER any data that were not expected (excess TMR). 
Thus, all 5XB COER data missing for this district are accounted for 
by the DEF TMR, which is the difference between what COER was 
told to expect and what TDAS was told to forward by their respective 
record bases. 

The next two columns of the PIR, feature ©, give the number of 
validation tests performed by COER and the number and percent that 
failed. Validation failures are performance measurements, but the 
absence of asterisks indicates that none of the TU's are in band U for 
that measure. If the administrator, however, sees the failures exceeding 
reasonable rates for any TU, detailed information can be obtained as 
described later. 

The last column of the PIR indicates where the COER internal 
record base validation tests have detected a record base inconsistency 
(control file error). None has been detected in this district. 

Thus, perusal of this week's PIR indicates that the only severe 
problem is a data loss for one TU caused by a scheduling mismatch 
between the TDAS and 5XB COER record bases. 

After the PIR and its accompanying footnotes are printed, CSAR 
asks the user to enter a TU name if further details are desired. In this 
typical example, the last line of Fig. 2 shows that the user responded 
with MRCYLAINMGO, the TU having the missing data. A 5XB 
COER Traffic Unit Details Report, Fig. 3, is generated from that 
request. The top section of this report, feature ©, is a repeat of the 
PIR format for the one TU. This redundant information is included 
in the details report so that the report is complete for that TU without 
requiring reference to the PIR. A few lines below, feature © shows the 
status of the data input to 5XB COER. The interpretation of this 
information, guided by the appropriate on-line lesson, is that six one- 
hour intervals (ending at 10:00, 10:30, 11:00, 11:30, 16:00, and 16:30) 
are expected by COER on all of the weekdays. However, the data 
expected for the one hour ending at 11:30 (between 11 and 12 on the 
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Fig. 3— A 5XB COER traffic unit details report. 

figure) were not provided to 5XB COER because they were not 
scheduled through TDAS on a TMR. 

Thus, the 5XB COER details report can serve as a comprehensive 
trouble indication to organization(s) responsible for scheduling 5XB 
traffic data for this TU. In this case, the analysis and trouble referral 
would be complete after a brief on-line computer session. 

The bottom of Fig. 3, feature ®, gives details on the data validation 
tests. When the TU validation failures are higher than an experienced 
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administrator thinks is normal, they could use these details to deter- 
mine which component tests have abnormal failure rates. 

The last two lines of Fig. 3 show the dialogue for optionally obtaining 
access to further information from other systems in the TNDS for 
this same TU. In this example the user continues the analysis by 
requesting complete TDAS details on all TMRs for this TU week. 

4.3.2 Performance summaries 

The Performance Summary Reports (PSRs), derived from weekly 
results in the database, evaluate performance in the TNDS operation 
for management at all levels of the telephone company organization. 
The summaries are available for one or all systems in the TNDS. The 
summarization technique determines individual traffic unit results for 
each performance measurement and places each traffic unit measure- 
ment into the appropriate band: Objective, Lower than Objective, or 
Unsatisfactory. As we discussed earlier, this banding technique avoids 
averaging the results across entities and masking specific cases of poor 
performance. As shown in Fig. 4, the summarized results reported are 
the number of traffic units and the percentage of traffic units in each 
performance band for each measurement. Totals are included on a 
system basis in the TNDS, along with grand totals. The on-line 
summarization is computed for the time period specified by the user 
(one or more study weeks) and for a requested organization (one or 
more traffic units). 

As part of the regular CSAR processing, an official performance 
summary is run for monthly results of the total company. These 
results for the Service Observing Month (SOM) are then retained as 
part of the CSAR database. The grand total results for each company 
constitute the official input to TPMP. 

As an aid to isolating and correcting problems CSAR also generates 
an optional list of all traffic units that appear in the unsatisfactory 
category (Fig. 5). This list can serve as a trouble list, and appropriate 
remarks regarding disposition and/or remedy can be made in the 
comments column. 

4.3.3 Performance monitors 

In addition to traffic unit banding and summary aggregation, CSAR 
also monitors other aspects of TNDS operations that are not within 
the scope of TPMP. Performance Monitor reports serve this important 
purpose and include the following areas of interest: 

1. Common Update transaction statistics 

2. Collection machine downtime 

3. TNDS processing timeliness 

4. TNDS software abnormal terminations and run times 
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Fig. 4— Performance summary report. 

5. TSS data by servicer responsibility. 

These reports present an additional view of the effectiveness of data 
collection equipment and various company organizations. 

4.3.4 Unsatisfactory results display 

The management users of CSAR often prefer results that more 
clearly reflect general performance levels, trends over time, and direct 
comparison between organizations or between the component systems 
of the TNDS. The Unsatisfactory Results Display reports plot the 
poor performance (band U) in a series of horizontal bar graphs. The 
graphs are simple in appearance and offer a wide variety of options 
that reveal performance trends at a glance. The results can be plotted 
with subtotals by any system in the TNDS, or by the organizations 
that are directly subordinate to the one requested. For example, as we 
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Fig. 5— Performance summary report showing unsatisfactory traffic units. 

see in Fig. 6, an area manager can request a five-week performance 
graph containing an area total and subtotals for each of the divisions 
in that area. The official summary results are also available as graphs. 

4.3.5 Bell System summaries 

Analysis of TNDS performance can extend to the level of the entire 
Bell System when the performance results for all OTCs are aggregated 
together. Here, there is an opportunity to assess the need to modify 
TNDS, systems or operating methods in the CSAR itself. There are 
four types of reports available at this level. One gives Bell System 
total results in the form of the "Brief version of the Performance 
Summary report (no band U list). The "Company" option, when 
exercised, produces a report of the number of performance measure- 
ments falling into each of the bands O, L, and U for each company. 
The "graph" option generates a graph of the band L and band U 
results by company. The remaining option is especially valuable for 
TNDS and CSAR project managers at AT&T and Bell Laboratories. 
This "Measure" option generates a list of each company's percentages 
and the Bell System totals in bands O, L, and U for each of the 
performance measures. Thus, problems common to a large cross sec- 
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Fig. 6— Unsatisfactory results display. 

tion of users can be examined to determine what system design or 
training efforts might be appropriate. 

4.4 Database controls 

CSAR creates and maintains separate central databases for each 
OTC using the system. On-line database controls permit the CSAR 
coordinator or Headquarters staff personnel to decide on the size of 
the database, the retention periods of three classes of performance 
information, the timing of certain automatic CSAR processing, and 
the organizational structure to be used for reporting purposes. Each 
of these controls may be exercised at any time to adapt to changes in 
data needs, company reorganization, storage costs, and other consid- 
erations. 
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4.4.1 Data retention 

While the current week or current Service Observing Month (SOM) 
performance results are of primary interest, past results can also be 
examined for evidence of trends or persistence. To provide this histor- 
ical perspective, CSAR databases contain fundamental performance 
data organized on a TNDS subsystem and traffic unit basis for distinct 
study weeks. In addition, summarized performance results are stored 
for each SOM. Because different classes of performance data serve 
distinct purposes and make significantly different demands on the 
physical database storage capacity, three data retention parameters 
are available to the user: 

1. Short-term Retention (STR) (from 6 to 16 weeks) 

2. Long-term retention [from (STR+5) to 52 weeks] 

3. Official results retention (from 12 to 30 months). 

The most voluminous data, deleted after the short-term retention 
period, are the supporting details from which the weekly results are 
derived. These details reflect TNDS processing at the half-hour, or 
hourly, level, and include measurements in terms of TDAS Data 
Collection Units (DCUs), switching office equipment components, 
Trunk Servicer responsibility codes, etc. This fine level of detail helps 
the CSAR user to track and isolate specific problems. The data analysis 
algorithms also require these data to correlate cross-system effects, 
and accurately calculate the weekly traffic unit measures. 

Weekly performance results are kept for a period of several months 
(long-term retention), and SOM results are retained for more than a 
year (official results retention) so that performance can be compared 
under similar seasonal conditions. 

During the CSAR Batch processing the data retention restrictions 
are applied, all outdated database information is automatically deleted, 
and the storage space is freed for future use. 

4.4.2 Organizational map 

The user-defined CSAR organization map provides a direct and 
dynamic control over database retrievals. The CSAR user is presented 
with a hierarchical logical view of the performance database for on- 
line retrieval purposes. Unlike most hierarchical database manage- 
ment systems, the hierarchy is not a static structure defined at 
database generation time; instead CSAR provides a flexible structure 
that can be modified easily on-line without database reorganization. 

The basic reporting unit for most CSAR information is the traffic 
unit. Data tracking and problem diagnosis for the TNDS is most 
successfully accomplished by analyzing the scheduling, collection, 
processing, and validation activities at a fundamental traffic unit level. 
Data reported at this low level reveal problems that can be isolated to 
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specific physical devices, user transactions, record base items, or 
operational procedures. For performance measurement of complete 
systems, functions, or company organizations, and for more effective 
management use of the information, aggregate views of traffic unit 
data are more appropriate. Responding to these needs, CSAR provides 
flexible multi-level views that permit data access at any organizational 
level, from the elementary traffic unit up to the entire company. 

The user defines a hierarchical structure (up to nine levels) that 
establishes a company organization desired for CSAR reporting pur- 
poses. The first or top level is reserved for the company name, and 
the lowest level is designated as the traffic unit level. The remaining 
seven hierarchical levels can be named to represent the company 
structure and levels of management responsibility (i.e., district level, 
division level, area level, etc.). Not all seven intermediate levels have 
to be defined. At each of the levels two through eight, one or more 
entities can be named and placed subordinate to an entity named in 
the level above it. Figure 7 shows an organizational map with a total 
of five levels. 

The CSAR map logically associates each of the many company 
traffic units to the desired organizations identified in this hierarchical 
structure. The physical database storage of traffic unit performance 
data is completely independent of this logical hierarchy. The CSAR 
dialogue then allows groups of traffic units to be collectively requested 
by any designated organization at any level. 

The map's structure and the association of traffic units to higher- 
level organizations is defined using special data-entry features of the 
CSAR dialogue. A complete set of update commands allow the user to 
add, delete, change, rename, and move individual traffic units, com- 
plete organizations, or levels. The changes are performed on-line with 
the resulting organization in effect immediately for all subsequent 
report requests. CSAR features also include the ability to list the map 
in a variety of ways to determine or verify the current company 
organizational structure. 

The direct control over a retrieval hierarchy and the ability to 
modify it easily make the CSAR organizational map a most versatile 
and innovative system feature. 

4.5 Processing controls 

CSAR on-line features can override certain automatic batch proc- 
essing functions. These controls are enacted through the normal CSAR 
dialogue, but only by the privileged headquarter's users. The overrides 
exist to meet two types of needs: (1) a management demand for an 
early assessment of official monthly results; and (2) an administrative 
need to respond quickly and conveniently to batch processing prob- 
lems. 
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4.5. 1 Generating official results 

A process delay parameter, entered as a company option, defines 
the longest expected delay between the collection of traffic data and 
the delivery of the TNDS performance data to CSAR. The database 
loading process closely monitors actual data delay, particularly to 
determine late data impact on official TPMP monthly results. The 
official performance summary results are generated automatically 
during the CSAR batch process after the appropriate period of time 
has elapsed. In cases where management personnel require official 
results prior to the expiration of the process delay period, CSAR 
permits on-line interactive generation of the official performance 
summary. This on-line feature enables the administrator to satisfy 
immediate needs or to correct past results by regenerating summaries 
in the event of unexpected, very late data. 

4.5.2 Batch job control 

Process control features also exist to simplify overseeing the data 
transmission and CSAR batch database loading process, described in 
Sections 3.1.2 and 3.1.3. Each OTC's administrator responds to ab- 
normal completion of CSAR batch jobs. Interactive features include 
Rerun and Remove commands allowing direct control over the dispo- 
sition of individual data transmissions that were received but not 
successfully processed. These controls are exercised after the admin- 
istrator determines the nature of the problem using diagnostic and 
error recovery information supplied by the system. 

4.6 Administrative reporting 

The telephone company administration of the CSAR software sys- 
tem requires activities such as: initial implementation, organizational 
map definitions and maintenance, selection of company options, co- 
ordination of data transmissions, and monitoring of the ongoing data 
processing. Each OTC has a designated CSAR administrator. Some of 
CSAR's features simplify the administrator's job. The data transmis- 
sion and database entry operation have been automated to the fullest 
extent possible. The CSAR database provides on-line interactive ac- 
cess to status information and various reports that assist in system 
administration. The administrator relies on several sources of infor- 
mation to monitor the overall operation of CSAR: 

1. Local and global login messages 

2. News items 

3. Tape processing status 

4. Batch data processing summary 

5. Map Data Discrepancy report 
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6. Interactive feature usage statistics 

7. Operational cost information. 

When an administrative user logs on, the Messages, News Items, 
and Tape Processing Status display important happenings without 
the need for database query. Based on any abnormal terminations 
indicated on the tape status, the corresponding batch job is investi- 
gated by accessing the Batch Data Processing Summary. The summary 
serves as a log of all processing activities and contains any error 
diagnostics identified by the CSAR software. Many conditions can be 
effectively identified and corrected by the administrator. Other prob- 
lems may require investigation by the central development organiza- 
tion, and the error message would instruct the user to initiate the 
trouble referral. 

The entry of new data into the CSAR database may involve traffic 
units that had not been anticipated, or for some reason not properly 
defined in the company organization map. The performance data are 
retained for these traffic units and are entered into the database. In 
addition, each previously unknown traffic unit is temporarily added 
to the map directly subordinate to the company level, where it remains 
until the administrator uses the CSAR dialogue to move the traffic 
unit to the appropriate position in the organization hierarchy. CSAR 
alerts the users of any such unexpected or unusual conditions via a 
Map Data Discrepancy report, and by Input Data Anomaly sections 
of the Batch Data Processing Summary. The software system design 
incorporates similar error detection and supporting diagnostic infor- 
mation throughout to simplify system administration and mainte- 
nance. 

V. CSAR SOFTWARE DESIGN 

In the design of a software system several conflicting factors are 
addressed and balanced to provide an efficient, flexible system that is 
responsive to the user needs. Three aspects of CSAR software design 
deserve specific mention and are covered in the following paragraphs. 

5. 1 On-line response time 

A primary concern in the design of CSAR was flexibility in selecting 
the set of traffic units, TNDS systems, and time periods over which 
performance can be summarized. Depending on the particular request, 
tens of thousands of data items would have to be summarized on line 
and reported to the user. To accomplish this summarization with good 
on-line response time required special attention in the CSAR design. 
The physical database organization chosen reflects the high-level 
summarization options of "system" and "time period." Unique files 
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exist for each system/week that contain the key performance infor- 
mation for all reporting traffic units. CMS files are organized and 
accessed with a physical block size of 800 bytes. The key performance 
indicators for many traffic units are stored together in logical records 
whose lengths are an integral multiple of 800 (one TU requires much 
less than 800 bytes) to make efficient use of the operating system's 
file structure. File pointer tables exist to identify the CMS record 
(block) and location within the block for each active TU. The internal 
traffic unit identification scheme utilizes a hashing function together 
with the file pointer table to efficiently access the data for a particular 
TU within a file. The logical structure of the map efficiently converts 
the OTC organizational level to a set of reportable TU hash indices. 
Finally, the TU access order is optimized based upon the file pointers 
to minimize the amount of I/O necessary to read the raw performance 
data. These techniques used together result in worst-case summari- 
zation response times typically less than six seconds in an average size 
OTC. 

5.2 Flexibility in reportable measures 

The measurement plan consists of 19 individual performance indi- 
cators. These basic indicators have been refined several times since 
the measurement plan was first introduced to provide equitable re- 
porting across companies and to encourage continued performance 
improvement. 

The design of the software to support these changing requirements 
had to be robust and easy to modify. The identification of distinct 
measures, the start and stop effective dates, the banding thresholds, 
and other key information are all specified in a single file external to 
the software programs. During system execution this file is accessed 
to load tables that control the summarization process. This table- 
driven summarization approach is also beneficial in that the effects of 
proposed changes to the mesurement plan can be observed by editing 
a development copy of this file and using this modified version when 
accessing the OTC data. Many such modifications can be studied and 
later implemented without changing or recompiling any software. 

5.3 Overlay structure 

User chargeback generated by using this AT&T VM/CMS facility 
is highly sensitive to the core size of the virtual machine required for 
the application program. To minimize this aspect of chargeback, and 
to improve efficiency by reducing virtual storage paging, the system 
was designed with an overlay structure consisting of over 120 separate 
modules. The design of these modules reduced the total amount of 
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code generated by combining approximately 560 functional routines 
as building blocks. 

The overlay structure maintains common routines and information 
required throughout the on-line session in a root area that is never 
overlayed. Specific software required to respond to a particular user 
request is overlayed in multiple levels below the root. In the most 
complex request, eleven individual overlays are used, reducing the 
amount of incore storage required from 500 to 130 kilobytes. 

VI. CONCLUSION 

The goal of bringing performance measurements and operations 
analysis information to the TNDS has been achieved by implementing 
the TPMP through CSAR. TNDS managers and administrators now 
receive reports that are comprehensive, easy to obtain and use and on 
time. CSAR can be readily adapted and documented as TNDS changes. 
In fact, method changes are currently under way to improve the 
effectiveness of CSAR in isolating TNDS data collection and provi- 
sioning problems. Recent changes and future plans, not reflected in 
this article, include the revision or elimination of certain performance 
measurements. These changes will shift the emphasis from strictly 
end-system analysis to measurements that detect and quantify prob- 
lems of data availability earlier in the flow of data through TNDS. As 
data responsibilities have become better focused organizationally, 
TPMP has been reexamined to ensure the plan meets the changing 
needs of OTC managers. This article reflects the CSAR software 
system and TPMP methods as of the middle of 1982. 

CSAR became available to the OTCs in the last half of 1979. No 
official TPMP reporting was required by AT&T, however, until July 
of 1980. During the introductory interval, the OTCs began to use 
CSAR reports as effective tools for traffic data administration and 
management. At the start of the official reporting, the Bell System 
average for band U measurements was about 10 percent. (This is 
thought to be about one-half of what it was at the beginning of the 
introductory period.) The current Bell System average of band U 
measurements is about 5 percent. Thus, CSAR is providing effective 
in improving the delivery of valid traffic data so that the Bell System 
network can respond efficiently to customer needs. 
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